-- BP 7.1.6 content: ModelClass syschar: 3 persistence-version: 7.1.6

INSERT INTO O_OBJ
	VALUES ("cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	'Ordinal',
	411,
	'ORDD',
	'The ordinal core type automatically populated in the metamodel is specified as
ascending and based upon identifier, because the only known operation is for 
traversing a collection of object instances.
    To support other ordinal uses in a process model, the user must create a 
user-defined ordinal type.
    The below gives more detail on ordinals:
"Ordinal data types are used to express order, such as first, second, and so on.
However, the subject of ordering is a lot more interesting that just this 
common example; hence the following digression.
An ordering is always applied to a set of elements. The set can be finite or 
infinite. There are two types of orderings to consider. The first is the most 
familiar; it is a complete ordering. What this means is that you can express 
the concept of "before" (represented as <) between any two members of the set. 
Hence, 7 is before 26 ( 7 < 26 ). A complete ordering has the property of 
transitivity:
    If A is before B, and B is before C, then A is before C.
A practical example would be the ordering of the cars that make up a freight 
train. Assume we define a first car. Then we could pick any two cars and easily 
determine which one was before the other.
Far more interesting are the partial orderings. Consider this sketch of a 
partial ordering.
A -> B -> C -> D
          + -> E -> F -> G
Using the obvious interpretation, we can say that A < B (A is before B), C < D, 
C < E, and E < F. But we cannot say anything about the relationship between D 
and F: They are non-comparable.
Examples of structures that are partially ordered include PERT charts, trees 
used for any purpose, interlock chains, the connectivity of an electric grid, 
and the like. All of these can be modeled in complete detail using standard OOA 
relationships; for examples see [Starr96] and Chapter 4 of Shlaer-Mellor
Method: The OOA96 Report. Note, however, that when modeling such a structure, 
one frequently finds it necessary to employ quite a number of ancillary objects 
(such as root node, parent node, child node, and leaf node) together with a 
significant set of relationships  all required to express a generally 
well-known concept. While this can be quite satisfying when one is in a purist 
frame of mind, the pragmatist points out that such constructions are often of 
limited value, obscuring, as they can, the true purpose of the model. This 
becomes particularly pertinent when constructing models of an architecture, 
where ordering is a particularly prominent theme (see The Timepoint 
Architecture chapter). Hence we have defined the ordinal base data type, 
leaving it to the judgment of the analyst as for when to use an ordinal 
attribute as opposed to using more fully expressive OOA objects and 
relationships.

Returning now to the main theme, an ordinal data type is defined by:
    data type <data type name> is ordinal
The operations permitted for ordinal data types are
    - the comparisons = and != (identical and not identical in value)
    - the comparisons < (read as "before"), >, <= , and >= . Each such 
        comparison yields a data element of base type boolean if the ordering 
        is complete, and of base type extended boolean if the ordering is
        partial." [OOAData]
        NOTE: This metamodel doesn''t support an extended boolean type, so a 
        comparison of partial ordering will always yield false.
    - the set existence checks of empty and not empty" [OOAData]

Ordering implies a direct path where one can follow the path in any direction 
to determine what is before and what is after. Changing direction isn''t 
permitted (i.e., taking another path), and traversing multiple paths is another 
operation (e.g., get number of items after C on path 1 yields 1 (D), and get 
number of items after C on path 2 yields 3 (E, F, G); the total number of items 
after C is 4 (result 1 + result 2).
    Any comparison operations have to be done on the same path, so an "illegal" 
comparison across two paths will yield a false. The analyst must be cautioned 
about this rule, or the tool implementer could make such comparisons result in 
an error. This rule on paths obviates the need for an "extended boolean" as 
described in [OOAData].

Ordering is done based upon a common index value. This means that all the 
members of the ordinal must be of the same type, but not all types can be part 
of an ordinal. e.g., composites, booleans, ordinals, and enumerations.',
	"00000000-0000-0000-0000-000000000000");
INSERT INTO O_TFR
	VALUES ("20c4ee00-5d32-4ec3-89e6-7c03e5db6c2a",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	'generateSupportedOperators',
	'The operations permitted for instance reference data types are
    - the comparisons = and != (identical and not identical in value)
    - the set existence checks of empty and not empty.',
	"ba5eda7a-def5-0000-0000-000000000000",
	1,
	'generate TYOP_A1:create(name:"assignment", symbol:":=", type:"ordinal", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"join", symbol:"+", type:"ordinal", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"equal", symbol:"=", type:"ordinal", result:"boolean") to TYOP class;
generate TYOP_A1:create(name:"not equal", symbol:"!=", type:"ordinal", result:"boolean") to TYOP class;
generate TYOP_A1:create(name:"empty", symbol:"empty", type:"ordinal", result:"boolean") to TYOP class;
generate TYOP_A1:create(name:"not empty", symbol:"not empty", type:"ordinal", result:"boolean") to TYOP class;
generate TYOP_A1:create(name:"insert", symbol:"insert into", type:"numeric", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"remove", symbol:"remove from", type:"numeric", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"insert", symbol:"insert into", type:"symbolic", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"remove", symbol:"remove from", type:"symbolic", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"insert", symbol:"insert into", type:"boolean", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"remove", symbol:"remove from", type:"boolean", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"insert", symbol:"insert into", type:"arbitrary", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"remove", symbol:"remove from", type:"arbitrary", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"insert", symbol:"insert into", type:"duration", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"remove", symbol:"remove from", type:"duration", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"insert", symbol:"insert into", type:"time", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"remove", symbol:"remove from", type:"time", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"insert", symbol:"insert into", type:"instance reference", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"remove", symbol:"remove from", type:"instance reference", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"insert", symbol:"insert into", type:"function reference", result:"ordinal") to TYOP class;
generate TYOP_A1:create(name:"remove", symbol:"remove from", type:"function reference", result:"ordinal") to TYOP class;',
	1,
	'',
	"00000000-0000-0000-0000-000000000000",
	0,
	0);
INSERT INTO O_NBATTR
	VALUES ("79b81f5c-30b6-4475-8480-c8a708e6b98f",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO O_BATTR
	VALUES ("79b81f5c-30b6-4475-8480-c8a708e6b98f",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO O_ATTR
	VALUES ("79b81f5c-30b6-4475-8480-c8a708e6b98f",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	"c1b7a91e-5a52-4bbb-b52d-d2d77b4a7f2b",
	'order_specifier',
	'The order specifier attribute determines the basis of the ordering. The order 
specifier can be an object attribute, if the ordinal is composed of objects, a  
meta-attribute, e.g., identifier, name, etc., common ordering based upon data 
type, i.e., numeric +/- 1, alphabetical for strings, etc., or physical 
placement. (A TBD symbol or keyword will be defined to indicate placement.)
    Placement is to be considered ordered by a means external to the data. 
e.g., an array. A placement ordinal will have means of inserting, moving, and 
removing ordered elements. Placement ordinals will also have associated marks, 
so placement can be based on platform considerations. e.g., memory location, 
timestamp, etc.
    All ordinals will have the ability to add and remove elements.
    The order specifier can be dynamically changed in the process models. ',
	'',
	'order_specifier',
	0,
	"ba5eda7a-def5-0000-0000-000000000004",
	'',
	'');
INSERT INTO O_NBATTR
	VALUES ("7842a8d4-5451-4c01-8d92-05c367dd43b2",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO O_BATTR
	VALUES ("7842a8d4-5451-4c01-8d92-05c367dd43b2",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO O_ATTR
	VALUES ("7842a8d4-5451-4c01-8d92-05c367dd43b2",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	"79b81f5c-30b6-4475-8480-c8a708e6b98f",
	'direction',
	'Direction of ordering is either ascending or descending. The direction can be 
dynamically changed in the process models. A loop operation on the ordinal will 
follow the set direction.
',
	'',
	'direction',
	0,
	"ba5eda7a-def5-0000-0000-000000000002",
	'',
	'');
INSERT INTO O_REF
	VALUES ("cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	"457cd498-80ef-4e4e-95e0-56bc48607519",
	0,
	"c6811edb-d913-48b2-be3e-1d2ebba0547e",
	"ad325f35-faf5-44a4-ac99-a2f9909efbb9",
	"64723d22-bb56-4f1a-b7e6-e83da80fba22",
	"be141c7f-7bce-427c-8219-bd5767c973d9",
	"c1b7a91e-5a52-4bbb-b52d-d2d77b4a7f2b",
	"de5bcc28-7c7b-47a7-8e06-04dae546e2eb",
	"00000000-0000-0000-0000-000000000000",
	0,
	'',
	'Core',
	'name',
	'R403');
INSERT INTO R_RGO_PROXY
	VALUES ("cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	"ad325f35-faf5-44a4-ac99-a2f9909efbb9",
	"64723d22-bb56-4f1a-b7e6-e83da80fba22",
	'../Type.xtuml');
INSERT INTO O_RTIDA_PROXY
	VALUES ("c6811edb-d913-48b2-be3e-1d2ebba0547e",
	"457cd498-80ef-4e4e-95e0-56bc48607519",
	0,
	"ad325f35-faf5-44a4-ac99-a2f9909efbb9",
	"be141c7f-7bce-427c-8219-bd5767c973d9",
	'../Type.xtuml');
INSERT INTO O_RATTR
	VALUES ("c1b7a91e-5a52-4bbb-b52d-d2d77b4a7f2b",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	"d59bff5d-0418-4222-8cac-0ab92a87871f",
	"0c8bafe9-416d-4662-a4ec-206f276b9ac5",
	1,
	'name');
INSERT INTO O_BATTR_PROXY
	VALUES ("d59bff5d-0418-4222-8cac-0ab92a87871f",
	"0c8bafe9-416d-4662-a4ec-206f276b9ac5",
	'../Type/Type.xtuml');
INSERT INTO O_ATTR
	VALUES ("c1b7a91e-5a52-4bbb-b52d-d2d77b4a7f2b",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	"00000000-0000-0000-0000-000000000000",
	'name',
	'',
	'',
	'name',
	0,
	"ba5eda7a-def5-0000-0000-000000000007",
	'',
	'');
INSERT INTO O_NBATTR
	VALUES ("55d0c522-70f7-4162-9971-d6a1b0207614",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO O_BATTR
	VALUES ("55d0c522-70f7-4162-9971-d6a1b0207614",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO O_ATTR
	VALUES ("55d0c522-70f7-4162-9971-d6a1b0207614",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	"7842a8d4-5451-4c01-8d92-05c367dd43b2",
	'current_state',
	'',
	'',
	'current_state',
	0,
	"ba5eda7a-def5-0000-0000-000000000006",
	'',
	'');
INSERT INTO O_ID
	VALUES (0,
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO O_OIDA
	VALUES ("c1b7a91e-5a52-4bbb-b52d-d2d77b4a7f2b",
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	0,
	'name');
INSERT INTO O_ID
	VALUES (1,
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO O_ID
	VALUES (2,
	"cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12");
INSERT INTO PE_PE
	VALUES ("cbbb7c7b-8a2f-4e22-b17f-b8ab1d093e12",
	1,
	"03ad3705-d9c8-45b5-a34b-f270ac9fc479",
	"00000000-0000-0000-0000-000000000000",
	4);
INSERT INTO EP_PKG_PROXY
	VALUES ("03ad3705-d9c8-45b5-a34b-f270ac9fc479",
	"00000000-0000-0000-0000-000000000000",
	"c8b88000-dddc-4206-8410-2f69b8f86b67",
	'Type',
	'',
	400,
	'../Type.xtuml');
